feat: add support for resolve extensions esbuild setting #510
Conversation
…e file extension prefixes
|
Hey @JohnGrisham, thank you for the contribution. And as you are adding a new configuration property could you please add it in the docs with short explanation. |
Practically for that example you could be connecting to a dev database in the dev lambda and a prod database in the prod lambda. Also in that example if neither of those lambdas were available or if the environment was not dev or prod then the default |
…build setting, updated readme
|
@floydspace I have made the requested changes, please let me know if there is anything else I can clear up or change. |
|
LGTM, I gonna merge it, hope it will be useful for others thank you for contribution |
|
🎉 This PR is included in version 1.50.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Support the ability to add custom resolution extensions via ESbuild settings. This is a feature of ESbuild and will allow for customization of lambda entrypoints. My team will be using this to support building different files based on the target environment we are deploying to.
Example:
myLambda.dev.tsmyLambda.prod.tsmyLambda.tsWhen the environment we build for matches the extension of the file then that entrypoint will be used otherwise it will fallback to the default file resolutions in the order of our choosing. If the user of this plugin doesn't pass a
resolveExtensionsESbuild setting then it will fallback to the array that was already defined by the repo.https://esbuild.github.io/api/#resolve-extensions
Notes:
When using custom extensions as the entrypoint for lambdas AWS can complain if the file uses a custom extension. To resolve this I have also added a
stripEntryResolveExtensionsoption to the plugin which will remove custom extension prefixes if they are used in the resolveExtensions list. This will result in files that have extensions liketest.custom.jsto be renamed astest.jsin the eventual packed file. I'm open to suggestions if there is a better way to handle this or if this behavior should be the default for any custom extensions assuming the approach in this PR is approved.